In 3GPP the evolution of the UMTS architecture is discussed in 3GPP TR 23.882, “3GPP System Architecture Evolution: Report on Technical Options and Conclusions”, V. 1.0.0 (available at http://www.3gpp.org), incorporated herein by reference. The motivation for the evolution is—among others—the development of a new air interface and the support for mobility between heterogeneous access networks.
An exemplary logical high-level architecture for the evolved system is shown in FIG. 1 and comprises at first an Inter Access System Anchor (Inter AS Anchor), being a user plane anchor for mobility between different access systems and supporting handover between different access systems. Functions of the anchor are, e.g.                Packet routing and forwarding,        Authentication, authorization and key management,        Policy and Charging Enforcement Function,        Gateway to PDNs, including IP address allocation from PDN address space        
Furthermore the architecture comprises a Mobility Management Entity (MME) and User Plane Entity (UPE). The functions of the MME are, e.g.,                Management and storage of UE control plane context,        Mobility management,        Authentication, authorization and key management,        Ciphering/integrity termination for signaling,        Management and allocation of temporary user identities, and the functions of the UPE are, e.g.,        Management and storage of UE user plane context        Packet routing and forwarding,        Policy and Charging Enforcement Function,        Ciphering termination for user plane traffic,        Trigger/initiation of paging when downlink data arrive for the UE in idle state.        
The MME, UPE and Inter AS Anchor are logical entities, i.e., the functionalities can be, e.g., deployed in different physical entities or combined in one single physical entity. Furthermore it is possible to have multiple MMEs, UPEs or anchors within one operator domain. Thus, with multiple MMEs/UPEs the data packet route from the anchor to the UE can be optimized, or the load can be shared between different MMEs/UPEs. In addition the network can provide connectivity to different PDNs (Packet Data Networks) over one or multiple Inter AS Anchors in the operator domain.
In the evolved system, the terminal (UE) must be registered (attached) with the network to receive services that require registration. During the first registration with the network, a Default IP Access Service is established, the UE is provided with an IP address and a default context (comprising e.g., UE/user identities, mobility state, tracking area, security parameters, QoS information, internal routing information and other parameters) is established in the network.
Further, in order to be able to send and receive user data, the UE must be in an active state with the 3GPP interface. In this state a radio connection is established and the UE reports measurements and requirements to the base station. Then, bearers are established between the UE and the network, carrying first the signaling and later the user data.
During mobility in active state the UE continuously measures the signal strength of neighbouring cells and sends measurement reports to the network. When the network decides to use a new base station, it establishes a new radio link and triggers the UE to handover to the new base station.
In addition to the active state a mode with lower power consumption is supported. This mode is called idle state and is used when no user data is sent or received. In idle state the cell reselection is performed by the UE and only tracking area (TA) changes are registered with the network (i.e., not every cell change is reported to the network). The network does not know the actual location of the UE on cell-level, but only on TA-level. In idle state UE related contexts are deleted in the 3GPP radio access network (RAN) and it is possible to page the UE.
For the sake of completeness the state where the location of the UE in the 3GPP radio coverage is not known by the network at all (e.g., the UE is switched off) is the detached state.
In case a service requested by the terminal requires a specific QoS, which cannot be provided by the Default IP Access Service, additional bearer services are required. For this purpose, either the UE or the network requests additional resources. For example, in case of IMS services (see 3GPP TS 23.228, “IP Multimedia Subsystem (IMS), Stage 2”, V. 7.2.0, available at http://www.3gpp.org, incorporated herein by reference), QoS requirements are signaled during application signaling, the Policy and Charging Rules Function (PCRF—see 3GPP TS 23.203, “Policy and charging control architecture”, V. 0.4.0, available at http://www.3gpp.org, incorporated herein by reference) authorizes the QoS and triggers the resource establishment. At the MME/UPE the UE's subscription is checked, admission control is performed and the resource establishment is initiated towards the RAN.
As mentioned above, the evolved system supports access to 3GPP services from non-3GPP radio access technologies as well. For this purpose either the Inter AS Anchor provides an IP interface and a UE can connect from a non-3GPP access system to the anchor directly via the IP interface, or another gateway provides the IP interface the UE is connected to, and the gateway is further connected to the Inter AS Anchor. Because of the IP connectivity between the UE and the gateway/anchor over a non-3GPP network, the connection is connectionless and unreliable. Thus, the Inter AS Anchor is not aware whether the UE is reachable or not.
For mobility between 3GPP and non-3GPP radio access technologies a UE with multimode capabilities is required. When the UE performs a handover from 3GPP to non-3GPP, the Inter AS anchor is informed about the location of the UE (e.g., in form of an IP address assigned to the terminal in the non-3GPP network or in form of another identifier of a tunnel endpoint the terminal is connected to). In addition to the location information the Inter AS anchor is provided with information about the user data packets (e.g., IP flows or packets marked with specific DiffServ Codepoint) to be transferred to the UE over the non-3GPP network.
The decision, which user data packets can be transferred over the non-3GPP network may e.g., depend on user subscription or operator policies. For example, for Voice over IMS (VoIMS) low delay is the main QoS requirement. The connection to a non-3GPP radio access technology may however provide high data throughput but with highly variable delay. Thus this connection should not be used for the VoIMS service. In case the operator employs different Inter AS Anchors for different services (e.g., one Inter AS Anchor for IMS services and another Inter AS Anchor for Internet services), one Inter AS Anchor might not provide the service for non-3GPP radio access technologies and thus not support mobility to non-3GPP (see Inter AS Anchor 1 in FIG. 2).
In one exemplary scenario a multimode UE has a non-3GPP and a 3GPP network interface and has an activate connection over the non-3GPP radio access technology. Furthermore, the UE wants to receive a service where either policies forbid to use the non-3GPP radio access technology or QoS requirements cannot be met in the non-3GPP radio access technology. Hence, the 3GPP network interface must be used for this service.
For being able to receive the 3GPP service over the 3GPP network, the UE must be either in active or in idle state. In the former case, the service activation and service delivery can start immediately. In the latter case, the UE is listening to paging messages and can set up a bearer after being paged. However in either states, the power consumption of the UE is significantly increased, because the 3GPP interface is active even when only the non-3GPP interface is used.
A work-around considered in an exemplary embodiment of the invention is to deactivate the 3GPP interface of the UE (i.e., the UE is detached) and to trigger the activation of the 3GPP interface over the non-3GPP network connection. Then, when the 3GPP interface is activated, resources can be set up and the application can be used. But with this solution the problem arises that the service activation is delayed until the connection with the selected 3GPP access network is completely established.
Hence, another potential problem is support of fast establishment for incoming connections over the 3GPP radio access and to enable low power consumption for multimode UEs at the same.